DevelopersIO 2022 データ変換パイプラインをdbtでレベルアップ #devio2022

さがらです。

DevelopersIO 2022において、dbt Labs社よりビデオセッションとして発表をして頂きました。

本ブログでは、こちらのビデオセッションのアウトラインをまとめます。（詳細はぜひ動画をご覧ください！）

セッション概要

概要

• 原文

Have you heard about dbt, but perhaps not sure what it is or what it can do for your team? Join us for this demonstration where you’ll get to see dbt’s workflow and implementation best practices first hand. The session will cover how to develop, test, document, and deploy data models with dbt Cloud, following software engineering best practices to boost collaboration and productivity. Looking forward to seeing you there!

• DeepL翻訳

dbtのことは知っているけど、どんなものなのか、何ができるのか、よくわからないという方。このデモでは、dbtのワークフローと実装のベストプラクティスを直接ご覧いただけます。dbt Cloudを使ったデータモデルの開発、テスト、ドキュメント作成、デプロイの方法を、ソフトウェアエンジニアリングのベストプラクティスに従って解説し、コラボレーションと生産性を向上させる方法を説明します。皆様のご参加をお待ちしております。

動画

目次

• 00:00 オープニング
• 00:18 アジェンダ
• 00:44 dbtとは
• 03:09 dbt core & dbt cloud
• 05:55 デモ（dbt coreとdbt cloudの共通機能）
• 17:59 デモ（dbt cloud特有の機能）

登壇者

• Bobby Birstock氏
  • dbt Labs Partner Engineer

dbtとは

dbtは、データ変換処理を担うフレームワークで、データアナリストやデータエンジニアがデータプラットフォーム上でデータ変換処理を構築・実行できるようにするものです。

dbtはコミュニティも活発で、dbtのSlackコミュニティには（撮影日時点で）32000人を超えるメンバーが在籍しています。

dbtには大きく2つのコンセプトがあります。

• dbtのフレームワークはSQLをベースにしていること
  • SQLはデータの専門家の間で広く使われている言語のため、どのクラウドデータウェアハウスでも、どのデータチームでも、dbtを採用できる
• ソフトウェアエンジニアのようにデータモデルを構築することを可能にできる
  • モジュール化されたコードの再利用、テスト、ドキュメンテーション、など

次は、dbtのデータエコシステムにおける位置づけについて見ていきます。

dbtはデータプラットフォームやデータウェアハウスの上に位置する、データ変換レイヤーに該当します。

BIツール、機械学習を始めとした、様々なニーズに対応するためにはデータクリーニングや変換を行う必要があります。

dbtを使用することで、様々なデータ変換処理をSELECT文ベースでソフトウェアエンジニアのように開発できるだけでなく、一連の変換処理をデータウェアハウスに対して実行することでデプロイする(本番用のスキーマにテーブル・ビューが作られる)、ということが可能になります。

dbt Coreとdbt Cloudの違い

dbtには「dbt Core」と「dbt Cloud」2種類あります。この違いについて見ていきます。

dbt Core

dbt Coreはオープンソースのツールです。

アナリティクスエンジニアリングのベストプラクティスに沿ってデータ変換を行うために必要な基本的な物がすべて含まれています。具体的には、データ変換処理の開発・テスト・ドキュメント化、を簡単に行うことが出来ます。

ただし、dbt Coreを使用する際にはいくつか技術的なスキルが必要となります。

• dbt CoreのインストールはCLIで行う必要がある
• 導入したサーバーのネットワーク設定
• サードパーティのスケジューラ(Airflowなど)を構成した上で、開発した変換処理を実行する必要がある

下図のスライドの左側は、dbt Coreを採用した際に必要となるツールを載せています。CLI、テキストエディタ、SQLコンパイラ、といったもので、これらのツールの導入し使用していくには技術的なスキルが求められます。

こういった事由から、すべての人がdbt Coreを使用できるわけではないですし、必要なインフラを構築・維持するのにも投資が必要となってきます。

dbt Cloud

dbt Cloudは、dbt Coreと比較した際により手軽に使用することが出来るソリューションです。

dbt Coreの説明で、CLI、テキストエディタ、SQLコンパイラが必要と述べましたが、dbt Cloudでは最初からブラウザベースの開発環境に統合されているため、自前で用意する必要がありません。

開発はもちろん、ログの閲覧、トラブルシューティングまで、dbt Cloud1箇所で行うことが可能です。

また、IDEだけでなく、Gitを使用したバージョン管理、ジョブスケジューラ、CI/CDワークフローの構築、もdbt Cloud上で行うことが出来ます。

デモ（dbt coreとdbt cloudの共通機能）

ここからは、dbt Cloud上の画面を用いたデモンストレーションとなっています。

動画では、05:55からデモを行っているので、ぜひご覧頂ければと思います。

このデモでは、Snowflakeに接続したdbt Cloudの環境を用いて、dbt CloudのIDE、dbt Cloudを用いた場合の開発・テスト・ドキュメント化の説明を行っています。

以下はデモで説明していることの概要ですが、動画ではdbt Cloudを実際に操作している画面と併せて説明をされています！非常にわかりやすいため、ぜひ動画もご覧ください。

IDEについての説明

• テキストエディタ
• Preview機能
  • 記述したコードをコンパイルして実行し、データウェアハウスから返ってきた結果を確認可能
• CLIインターフェース
  • dbt run、dbt testなどのコマンドを実行できる
• Gitワークフローを管理するボタン
  • コマンドラインでGitを使い慣れていなくても、このボタンを押すだけでGit操作が可能

dbtベストプラクティスを踏まえた開発・テスト・ドキュメント化のデモ

• Sourceの定義
  • dbtで変換したいデータウェアハウス上のソーステーブルの定義
  • Sourceに対して、テストやドキュメント化に関する設定も可能
  • Sourceを定義しておくことで、参照先のテーブルが変更となった場合でもSourceの定義1箇所だけ変更すればよい
• ステージングモデルの定義
  • ステージングモデルは、ソーステーブル1つにつき1つ構築するべき
  • 名称の変更や、型の変換など、シンプルな処理をステージングモデルでは実装する
  • Source関数を使うことで、Sourceを参照し、データリネージを生成できる
• データ変換モデルの定義と実行
  • dbt runコマンドにより定義したモデルを実行でき、--selectのオプションを付与することで指定したモデルのみ実行できる
  • モデルには基本的にSELECT文を書くだけで、そのSELECT文をCREATE OR REPLACE TABLEなどのDDL文に変換して接続先のデータウェアハウスに発行してくれる
  • IDEでの出力先は、開発ユーザー専用のスキーマに作られる（出力先のカスタマイズも可能）
  • ref関数を使うことで、モデル間の依存関係を構築しデータリネージを生成できるだけでなく、モデルの実行環境に応じて参照するスキーマも自動で切り替えてくれる
• テストの定義
  • dbt testコマンドで定義したテストを実行できる、--selectのオプションを付与することで指定したモデルに関連するテストだけ実行できる
  • dbt標準のテストでは、unique、not_null、accepted_values、relationshipsの4種類のテストが可能（テストについてはこちらのブログも、ぜひ併せてご覧ください）
• ドキュメントの確認
  • IDE左上のview docsを押すと、dbtにより生成されたドキュメントを確認できる（ドキュメントの生成には、dbt docs generateの実行が事前に必要）
  • ドキュメントでは、dbt上のyamlファイルで定義した各カラムの説明、適用しているテスト、各モデル間の依存関係、などが確認できる
  • ドキュメントのリネージ画面でUpdate Graphを押すと、対象のプロジェクト全体のリネージを確認できる

デモ（dbt cloud特有の機能）

続いて、dbt Cloud特有の機能に関するデモンストレーションを行っています。

動画では、17:59からデモを行っているので、ぜひご覧頂ければと思います。

以下は、デモで説明しているdbt Cloud特有の機能についての概要です。こちらも動画では実際にdbt Cloudの画面を操作しながら説明しておりますので、ぜひ動画を見て頂けると嬉しいです。

dbt Cloud特有の機能：スリムCIを用いたプルリクエスト発行時の自動テスト

• 開発環境で行ったことの確認
  • Mainブランチとは別に開発用のfeatureブランチを切り、新しいモデルを作成した
  • 新しいモデルについては、テストも定義済
• dbtのスリムCIについて
  • 通常、Mainブランチにマージしたいときには事前にプルリクエストを発行することが多い
  • dbt CloudのスリムCI機能を使うことで、プルリクエストが発行されたタイミングで開発したモデルの実行とテストを自動で行うことができる
• dbtのスリムCI機能の動作を見てみる
  • dbt CloudのIDEからopen pull requestを押すとGitHubに移動する
  • GitHubの画面では、featureブランチで開発したモデルとテストの内容が表示され、その画面上でプルリクエストを発行することができる
  • プルリクエストを発行すると、dbt Cloud内で事前に定義したCIジョブが動作し、ジョブに指定したコマンドを実行してくれる（CI用のスキーマに対して、モデルの実行やテストが可能）
  • モデルの実行とテストが上手くいくと、GitHub上でもテストが成功したことを確認できる。これにより、スムーズにプルリクエストの承認と、Mainブランチへのマージができる
• dbt CloudのスリムCIの設定方法
  • dbt Cloudでは、Environmentとして開発環境・CI環境・本番環境と、実行環境を切り分ける機能が備わっている
  • スリムCIを実行するには事前にCI環境とCIジョブの定義も必要
  • CI環境を定義した後、CIジョブの定義を行うが、いくつかポイントがある
  • CIジョブの設定ポイントその１：DEFER TO PREVIOUS RUN STATEの設定で、本番環境においてすべてのモデルを実行するメインジョブを指定する。これにより、CIジョブでは新しく開発したモデルだけを実行しテスト出来る
  • CIジョブの設定ポイントその２：CIジョブに設定するdbtコマンドに対して-m state:modified+をつける。これにより、新しく開発したモデルだけを対象とするだけでなく、+を末尾につけているので新しく開発したモデルの下流に位置するモデルも実行対象とすることができる
  • CIジョブの設定ポイントその３：Triggersの設定で、Webhooks欄のRUN ON PULL REQUESTSをONにする

こちらのCIジョブの設定については、DevelopersIOでもブログを投稿していますので、ぜひこちらもご覧ください！

最後に

dbt Labs社より発表頂きましたビデオセッションについて、アウトラインをまとめました。

dbtはOSSもあるため、社内のエンジニアスキルが高くリソースも十分にある場合にはOSSを使用した場合でも問題なく運用できると思います。

しかし今回のビデオセッションでもお話があったように、Coreを使う場合だと、

• CLIを用いたCoreのインストールと対象のサーバーの管理
• Airflowなどのサードパーティのワークフローツールの構築と運用

といったスキルが必要となり、一般的なSQLや分析業務に特化したデータアナリストだとスキルセットが異なるため、習得に時間がかかる面もあると思います。

そういったときにdbt Cloudを用いることで、上述したスキルを持たずともSQLの知識だけで、dbtのメリット享受しつつデータウェアハウス内のデータ整備を行うことが出来ます。

dbtを使いたいけどOSSだとハードルが高い…そんな方にはぜひdbt Cloudを検討して頂きたいです！